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THE ONLY WAY IT COULD WORK 
THE TRADEMARKS 
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AY IT COULD WORK — 


THE ONLY WAY IT CAN POSSIBLY BE DONE 


Some conventional methods, such 
as B-trees, permit rapid insertion  - 
and deletion in large. structures. 

TE | | - The slowdown as structure grows is 
— X logarithmic. | 


The ideas promoted in this book -> 
could not possibly be contemplated. 
unless methods of storage, editing 
and linking could be found which all, : 
singly and in combination, deterio- 
rated in performance as a logarith- 
mic function of the size of а docu- 
ment and the size of the docuverse. 

We believe we have achieved this. 

As in other dynamic-function prob-. 
lems, analytic proof is not possible, 
so this is an empirical question to 
be proven or disproven. | 
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UNING THE SYSTE 


We are concerned with the bal- 
ance of customer incentives to help 
foster our overall goals. In the 

The system's design is a unified coalescing final design of the sys- 
whole, but we may think of it as a tem, contracts, categories of ser- 
combination of structures: the basic vice and pricing are all subject to 
conceptual structure, plus a technical reconsideration. We need to study 
Structure which makes it possible, and Possible cost functions for reducing 
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a contractual structure which makes it possible Babel; 


possible for people to use it confi- 
dently. These aspects taken together 
make a unified design. Because the 
conceptual structure required very 
fast lookup within a tightly organ- 
ized but large linked system, we had 
to develop a particular technical 
Structure; and because the conceptual 
| Structure expects participants to. be- 
E have in certain ways, these are ES 
‚ braced in the contract offered to. 
| users. These provisions are neces- | 
sary” for the orderly and confident . 
. use of Pune shee тагара by тану. 
People. 


| LITERARY — 


or for cutting less- 
recent accessibilities in order to be 
practical. | 


The system has two business com- 


mandments, viz.: 


1. EVERYBODY MAKES MONEY: there 
exist many opportunities for Droste 
E clam с к nl 

2. ALL SERVICES MUST BE SELF 
SUPPORTING.» > | 


The ins Е will inves~ 


tigate Tamir саво: of the latter- 
premise. 
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ROYALTIES FOR WHAT EXACTLY? 


Granted that royalties should 
be exactly proportional to something, 
what should that be? 


If we make it "transmissions," 
some paradoxes surface. For in- 
"stance, if you the user have a fancy 
--computer ,. you and. your program. may. 
request many transmissions that are 
used little or not at all-- while 
certain materials, already transmit- 
ted, stay on Du do 


Fairness would Suggest that the 
material on the screen, not what goes 
over the wire, should be the royalty 
divisor. This would require certain 
back-reporting by the front end and 
may be a can of WOITS. but it cer- 
tainly has elements of fairness. 


We have considered schemes for 
getting reports back from the user 
systems-- optional with the user-- 

. Stating, on an honor-system basis, 

‚ where the royalty-fragments should 
go. that are not measurable at our end 
as transmissions. But this may Бе. 
too much flex; and many clo 

award the royalties to thei 

lished works. So there is [а case a- 
gainst this just on the basis of 
Straightforwardness. 


transmission. 


Or consider the user who hasa- 


low rate of transmissions, say 50% OR | 


the channel capacity if he chose to ` 
ask for fetches at full rate. 
20$ of the royalty go to the authors 


he used, апа the rest to the author' S к 


fund?. 


 BOUNCE-THROUGH ROYALTIES ^ 


When you use somebody's direc- 
tory, you bounce through their speci- 
fication to another document. What. 
royalty goes where? (We want to en- 
courage the creation of directories, 


. SO these authors should be rewarded. y 


However, we also want to kien: 
royalty a fixed rate. 


Опе solution: transmit the full 


address of the desired document, 


which would yield a royalty propor- 
tional to the address length to the 
directory owner. He could even in-. 
crease the incentive by increasing 
artificially the length of this 
But this reduces the . 
capacity of the user' 5 Tem by 
Е him down. = 
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MARKET-PRICING CONTROVERSY: 


FIXED VS. VARIABLE 


There are two schools of thought 
with respect to the pricing of these 
services. Surely the amount trans- 
mitted should not vary the price, 
since that would discourage high 
mental rates-- not what we want at 
all. 


‘One school of thought has it 
that certain flat, predictable char- 
дез-- such as ten dollars an hour or 
two dollars an hour-- depending on 
class of service-- are the best way 
to go. We can call this "smorgas- 
bord" pricing-- one price for all. 

It has the special advantage of avoi- 
ding hanky-panky in the accounting 
programs, which can then have conspic- 
uous checksums. Further, the user 
can predict his overall expenses 
nicely. Perhaps most important, a 
uniform royalty for all authors and 
documents is also desirable because 
this means there is no pretext for 
the system's keeping track of who | 
reads what. m РА 


"Therefore, just as the postofé 
fice subsidized the outlying stations 
on the basis of profits from the easy 
parts in the interests of uniform 
service at a uniform price, so might 
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Classical economics, however, M 
suggests a more buoyant pricing mech- ... 
anism, varying with time or system 
load-- "level-seeking," allowing за. 
market factors to enter in in a use- (ad 
ful fashion. | 





Ez Author Variations. 

One such market factor would be us 
to allow authors to set their own mE 
royalties-- very high, if they wan- 
ted. For now, in Balance I we have ©; 0 t 
opted not to келиге I 


25 Slack-time pee. Ре | 
in this view, unused capacity. 
should seek a "spot" market price, с. 
selling for less in short, or inter- 
ruptible blocks. | 


3. Market price of disk. 

In later stages, , allowing rental 
of disk to be distributed among var- . 
ious vendors, with some market-pri- 
cing mechanism, is not out of the 
question. | 


(Variant proposals to hold costs 
constant by slowing down service have 
been proposed, as a method of allow- 
ing the pricing mechanism to enter 
the situation while maintaining con- 
stant cost-per-hour and, e.g., char- 
ging higher royalties for materials 
for a specific source. On the posi- 
tive side, this allows pricing dyna- 
mics to operate and might allow users 














to "break through" to full perfor- 
mance at a higher cost. . On the nega- 
tive side, it is philosophically most 
disagreeable.) 


COST/TIME TRADEOFF 


Cost and time are often a con~ 
tinuum. On our system, various areas 


of кетбшайса can be slowed down at 


lesser cost. In both behind-the- 
scenes and up-front ways, cost/time 
playoffs are important options In. 9e 
the tuning of the system. 


nid iai" 


Users can ask for the moon and 
stars simultaneously. While early 
versions of the system will merely 
fetch what is asked for on a simple 
queuing basis, more sophisticated 
service algorithms will have to ra- 
tion. resources. 


The Resource Unit (RU) then be- 


comes a basic internal unit of soft- . 


ware accounting, dividing the sys- 
tem's effort on your behalf. A stan- 
dard customer gets one RU. (Ргіогі- 
ty customers might get more.) 


ness of it.. 
advertising subsidy is feasible. 


If one entity is called for, the 
search for it proceeds with a force 
of one RU. If two entities are 
called for simultaneously, each gets 
1/2 RU; and so on. RUs are divided 
as requests fan out. i С 


It is easy to see why this is 
necessary. The request fanout can 
easily become astronomical, which is 
all right; the problem is to find an 
orderly basis for servicing MIRVed 
searches (Multiple Independent Read- 
ing Virtuality). The divisible Re- 
source Unit keeps the overall Systems 
Effort equal to unity rather than 
inflating in combinatorial explosion. 


ADVERTISING 


The system does not discrimin- 
ate in any way among "types" of docu- 
ment by content. Advertising is thus 
perforce allowed. | | 


However, suggestions that adver- 
tising can somehow pay for general- 
ized use of the system, as with TV 
and magazines, have pitfalls. Speci- 
fically, there is no foreseeable way 
to find out what is actually being 
shown on a screen; thus advertising 
could be automatically screened out 
in many ways, defeating the useful- 
So it is not clear that 
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ARCHIVING 





It is mandatory that all sec- 
tions of the service be profitable. 
This puts the question of "archiving" 
on a curious basis. Here the trade- 
off between cost and time comes into 
sharpest relief. 


DISK STORAGE, on a unifying hy- 
pertext system, can be effectively 
instantaneous. But disk storage can 
last as long as somebody pays for it. 
After that you go to tape. 


THE TAPE PROBLEM 


What is on tape takes longer to 
get to. And bringing in materials 
for tape takes lots of time-- time 
that can worsen drastically as demand 
escalates.  ( In the degenerate case 
of queuing, of course, we go to re- 
peated Grand Passes of the corpus.) 


Immense automatic tape systems . 


are available, with little locomo- 
tives that go to the appropriate rack 


of tapes, pluck the one desired, 
slurp it in and put it back. But the 
maintenance of a large-scale tape li- 
brary is expensive-- though less, of 
course, than disk per unit stored. 





TWO SCHOOLS OF THCUGHT ABOUT ТАРЕ * 


One view is that disk and tape _ 
should be a unified whole, with all - 
that is on tape, an indefinitely 
expanding bundle, united to what is- 


on disk; though acd to ‘onpredic~ | 


table delays. 


However, this creates financial = — =" 
difficulties. Most of what stays on. 
tape is no longer being paid for or o= 
referred to. Storing the tape is ^ ^ 


cheap; hooking it up is expensive. 


Finding a viable economic arrangement | 


is the key pon E 


one solution, "and a probable л 


one, iz simply a RIDE 198 саре 
fetches. d 


(This in addition to the delay, 
which is an implicit charge. P, | 


ARCHIVING ARRANGEMENTS 


There may, after a point, have . 
to be a charge for long-term tape 
storage-- or for guaranteeing it. 

Our provisional solution is to define 
service arrangements, and the organi- 
zations to maintain them, rather like 
"perpetual care" mortuary arrange- 

ments. This will be discussed later. 






































BALANCE I 
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this particular tuning, I call Bal- 
ance I. It consists of the following the accounting). 
provisions: 


Two simple categories of privacy 





Fixed royalty, 5% of hourly charge, 
The overall scheme of incentives, so that the computation of royalty | 
is simpl e (to avoid xi E d lin v 


Fixed charge by hour; not by amount 
transmitted. (We want to encourage 
people to read a iot, not to reduce 
their intakel) | 


(published and private-- with 
private materials recallable, pub- 
lished requiring. 6-month depubli- | 
cation notice. "Privashing" recal- Note that this arrangement is 
lable, unlimited distribution, no . fair, orderly and simple. And these 
royalty. . . А сы E seem to me very important features. 
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If documents are used that have no- 
body for a royalty to go to, such 
as Shakespeare (or the use of your 
own private documents), the same 
amount goes to the Authors' Fund. 
A blue-ribbon panel assigns these 
proceeds to such purposes as typing 
in Persian poets or а: 
writers. 

Royalty to publishers of ets 
is proportional to the coordinate- 
material they transmit. 


THE QUESTION OF SPECIAL SERVICES 


In addition to the standard ser- 
vices, we could get into additional 
speedups within our philosophy (look- 
ahead, faster copies of specific ver- 
sions). Or we could imitate other 
services by adding admittedly-useful 

features that they have and we don't. 


| Consider scans. Many retrieval 
“Systems have fulltext scans for key- 
words. In doing that we are intrin- 


| sically less efficient than anyone 


,9lse, since they store blocks and we 
Store fragments. However, by storing 
concordances we could effectively a- 
chieve the same searches. Ideally 

. these would be concordances built 
concurrently with input typing. 

| These would enlarge storage for a 
| .given.document 1/5 to 1/3, however. 


But we must always remember that 


our specialties are the rapid deliv- 

ery of linked and windowing documents, 
and the assimilation and storage of зс 
changes. If we go far afield from uo 


this, our system could lose its power 
and ideals. | 


1/1 





Qu : 
ан эзле E LP oen "39 . -5-:4.9 A") a та "rw = 2 -— 2 E б PE э 
= ту enter pierce ИВА иена ЕАО 
VEO НИ ИУ, НЕ RZ 


TRENT 


ieee 


ЕЕ 


ЕЕ 











A a de rp ae ERO 


THE ТНАЙЕМАВК 


d.e ma Аг ae созун et Np seii vt 
xe T yu uc XE M кысы MM 


The following are the trade and 


: | T 
service marks of the system descri- he slogans 
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bed in this book, by which we dis- . К lightning Literature 
; ; | din : | The World of You 
tinguish our information services а : i 
| ME NN The Wings of Mind 
| and products from others. T . 
b "A c | Anything Instantly 
d | | BEEN | " г | " 
| "XANADU ™ to denote all our infor- od оа 
| mation services and products. M mA 
a "SilverStands "" to denote the sta- The following ‹ cartoon characters: 
D . tions at which service will be PORLOCK, т 
= provided. Z2 | ROSEBUD 
" "FREND'"" as an authorized and ap- The MARGINALIEN 
|. proved FRont-END program or con- i and E: 
| sole. THE HOBGOBLIN OF LITTLE MINDS. 
q " XANAMAII " to denote RSESOUNS mes- And finally that X-ternal Device, 
| sage services. The Eternal Flaming X 
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"XANADOODLE" for computer ees 
systems. _ 
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Our kingdom is already twice the size of Spain, 
and every day we drift makes it bigger. 


The Kaiser 
in е. s film 


| Besides the actual contents of 
our system-- text, graphical data, and 
other notations representing things 


"e people want to look at and manipulate 
o == the system must keep track of а lot 


of numbers. These are the internal 
numbers that are used for counts and 
pointers, and the overall scheme of 
_ where things are and how to get to 

‚ them. They are integers.* Some of 
these numbers have to be very very big. 
Others (in fact most of them) are 
small. 


| Our universe of documents (or 
docuverse) is potentially very large, 
and will grow unpredictably.  Numeri- 


“eal addresses in our system can there- 


fore grow very large. But they must 
also work with small increments and 


offsets. Designing the address space 
and notational representation is 
therefore crucial and difficult. 


It is not obvious-- it wàs cer- 
tainly not obvious to us at the outset 
-—- how to specify such a universe in 
any tractable form, with an indexing 
Scheme that can possibly grow very 
large and still retain any cogent mani- 
pulability when we deal with the nitty- 
Gritty small increments of changes 
within a given document. 


One — má would treat the 
docuverse as a large integer domain, 


sparsely occupied by assigned document . e 


addresses. That way lies madness: it 


would mean unoccupied. areas would use- а 
чр папу, шану erect оне. bits. м 





certain re d 









* ' Except whexe. floating-point and trigonometric functions are used for. 
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We drew some inspiration from the 
Dewey Decimal system, which, despite 
its faults, does not waste a lot of 


space on empty characters. This leads 
to insights about forking numbers, 
which we have developed in an unusual 
way. | | 


There are many kinds of numbers 
and notations for them. While it is 
customary in computer work to use sev- 
eral kinds of numbers (integers and 
floating-point numbers of different 


lengths, ASCII and BCD decimal trains), 


we use none of these in our current 
system design. For the interested 
reader, the types of numbers we have 
chosen to use are an interesting exer- 
cise in notational engineering. > -> 


Our solution has two parts. One 
is to use an accordion-like integer 
notation whose numbers are very short 
in representation when small, and as 
large as they need to be when big. 


The second part of the solution 
is to define an accordion-like master 
address space, potentially very very 
large, which includes notational pro- 
visions for the complex relations be- 
-tween documents, their forebears, 
their owners, their locale, and the 
expansion of the network itself. 








HUMBERS 
(Variable-Length Binary Integers) 


Humber stands for "Huffman-enco- ' 
ded number," which (strictly speaking) 
it is not; so if you prefer it stands 
for "humungous number." . 


Consider a byte.  - 


The first bif signals whether the 
number is complete in this byte. í 
this bit is unset, or zero, the re- | 
maining- seven bits hold the number it- 
self (g to 127), and the entire num- 


"ber is stored in the one byte. 


< A" "S 





If the Completeness bit is set, 


or one, that means the remaining bits 
of this byte specify the length, in 
bytes, of the number, in binary. 


Thus 


12 7X8 
the humber may range up to 2 


a number larger than needed very soon. 
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n Note, then, several advantages of 

this scheme. Small incremental hime 
bers are one byte long. But very 
large humbers adhere to the same for- 
mat; only one set of "humber arith- 

. metic" routines is necessary. 


rather. remarkable features. It is in-- 
tended to keep track of hereditary — 
successions of various kinds, while 
reducing the overall indexing manipu- 
lations to tractable arithmetic ощ 

We call it a tumbier. | 


para к оне ранна Res Сание вои We chose the моха "tumbler" Ыз? 
дө th PY = ce зи, є th m ly because it sounded like "number" 
Пе rds ep n е and "humber," and partly because of 
(when needed for small incrementation) 
its curious relation to the rotary 
and stretch out whenever needed with- 
mechanisms of locks, which also slide 
out any change in the generalized man- 
ipulation routines. No more ‘than sev- with respect to one а, and arg 
j also called "tumblers. 
, en bits are wasted in the length of 
the mantissa, and there is only the 


one-byte overhead of the specifier. The diabolical simplifying assump- 


tion that we have made is that there 


The Containment bit is zero if is really only one document. 


the actual number is within the byte, 
1 if it is not; this choice makes an 
all-zero byte a true zero (a fact 
which will be seen to be a useful 
choice for the tumbler mechanism, 
below). | 


A hypothesis built into the 
scheme is the notion that the number 
of compatible nodes will grow indef- 
initely but in hard-to-predict pat- 
terns. | 


| Thus a node, or station, is seen 
as having ancestors and possible des- 
cendants. An account, too, and a doc- 
ument, all have possible descendants... 


‘The Master Address Space: 
TUMBLERS 
Forking Multipart Integer Vectors, 


with Carr 
e ы For instance, consider that you.. 


The larger scheme for addressing е "— —— еар " 
, e. 


in the docuverse, our present one, 
employs a mut part number with some | 


Version Fork, leaving you two versions 








. fork on 20.2. 


| -are-required. 





which you choose to designate as sepa- 
rate versions, the original number 
being superseded.* Now these two are 
versions 20.1 and 20.2 (while the par- 
ent document, 20, in fact continues 


to hold most of the contents of both). 


Now suppose you do another version 
This yields 20.2.1 and 
M on. 


The entire tumbler works iike 
that: nodes can spin off nodes, ac- 
counts can spin off accounts; nodes 
can spin off accounts and documents; 
and. so on. Thus all numeration in the 
docuverse is comprised to a single 
mechanism. 


The tumbler format İs: 


NODE ACCOUNT DOCUMENT VERSION POSITION 
in version 


NO. №. NO. NO. 


Each of these fields may. nave one or 


more parts. 


Two different field separators 
 Presently we use the 
Secimal point i for duc а eee 


le p ma r 


within a given section; and the number 
Я (between decimal points) to sepa- | =a: 
rate the major sections. Thus a tum- | 


bler might look like: - 


B.9.0.7.3.2. 0.335.896 


(The fields missing between the first 
three zeroes show this to be an |incre- = 


mental tumbler. D 


(A fuller асарга ion of the _ 


tumbler is as p 


н.р. н. 5. H. lg. н. 2. н 


where "Н" is any hereditary multihum- = 


ber (series of humbers representing 


hereditary segmentation n decimal Or 


points as describen above. 


Thus a large а г might look 


like this: 
Rd 


where "i" is any integer, T EIE C es 


how you. like. 





* Whether a parent version number continues on to evolve as one of the 


Е: versions is a user 5 and thus a front-enå function. 


КТ: 







































































"Note that "time" is not included ~~ 
in the tumbler. This results in part. 


; ilati tween 
== que rad apa ар cope from the interesting hypothesis that 
umbers imal po : ` at some future time, document nodes. 


"understood," the decimal points | | md in z= 
Mr x E out: P may be in starships nearing the speed . Жо 
жы j | of light, so that their time records 

There is not time at the present will not transform directly to those. 


writing to explain the rules of tumb- kept at stable locations. Time is 


(Note that we have skipped over. 


ler arithmetic as worked out by the kept track of differently. 

group. Suffice it to say that tumbler 

addition is non-commutative (A+B does Note also that our demonstration 

not equal В+А) and therefore there are system uses standard integers as tum- 

strong and weak forms of subtraction bler fields, not humbers. However, 

(given A+B, both А-В and B-A). - | our coding is modulzrized in anticipa- 


mE tion of this upgrade. 

It will be seen that the tumbler | EET 4 нн A 
(and its associated routines of addi- Humbers are the work of Roger 
tion and subtraction) provides à mas- Gregory, Mark Miller and Stuart Greene, 
ter scheme for the full address space done in the summer of 1979. While it 
while handling increments and offsets went through many changes, and repre- 
-- whether local or very large-- with sents contributions by numerous mem- 
creditable brevity. These increments, bers of the Xanadu troupe, the present 
and offsets, naturally, can cross the form of tumbler was worked out by Mark 
lines between nodes and accounts, doc- 5. Miller, with help from Roland King. 
uments and versions. So it's all and Roger Gregory, in approximately 
really one big forking document. |. June of 1980. 













FEEL FREE 





GENERAL REMARKS 










The docuverse is the occupied No proprietariety is asserted for 


address-space. We do not waste numer-  humbler and tumbler methods or for 
ical positions on what is not there. their names; use them freely.  (In- 
As with Dewey Decimal, conceptual deed, they are а required part of the 
holes do not become utterly ineffi- front ends.) However, the group would 


cient notational holes. |». not mind a little credit now and then. 


etra 
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CREATENE DOCUMENT 





creates an empty document, returns docid. 


THE PROTOCOLS - 


INSERT “<doctd®? Cdoevea> Ctext^? 








pois 


Cdacido s= Itumb bers 
“geeyvsar t= ZtumbTer» 
ему t= char? | 


E" y | | AN | wee dot 
| puts siven text in document at eiven address, vstream addresses of — 
fallowine characters: if anys are increased bv lensth of inserted text. 








ЗЕ 5 MELETEVSPAN <iverec> 

E € ^ TR il ~N 

GE ivepec> t= Cdocid?-CsPanset^ 

Cepanset? t= Cseand# о аА GR  — E 








span» t= Ztumbler? Ctumbler? 





removes given spans from siven document, — 


REARRANGE <“idecid> Ccutset> 





5 
а 
^^ 


Zzutset2 t= Cncuts? Cdecvea>* | | 

i lmcuts? t= [intener> /& ncuts з 3 бог 4 #/ 

34.02€ | x ОЗИ ИЕА 
| IC cutset consists of 3 ar 4 veas within given document -- in 3-cut case | 
3——— — ————material-betueen ist and 2nd cuts is interchansed with that between 0 
W 1 ve | 2nd and Grd cuts. in 4-cut case material between Ist and 2nd is . . A 


- c Cs ipterchansed with that between 3rd and 4th. 








COPY Toi dd Cdecysa> <specset> 


(d CsPeceet? += Свресув 
CnePecs? te cinteser> о 
E fepeco += Фуврей» | (SPAN: | 
| 
| 


55е+ (siven vsrans of given documents). 


material determined Ev s | 
eminet ty decido? at address determíned 


hen I | i 
р Ee 5 а we o je copied te document dete 
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этеп, retuftns rou did. 
š ; Г 


НА СЕ ТМ drid Cdecvsas cbr mee 





ре он оз ая ge = 


Арг tS 20:15 19781 —)xudineutib 


creates link in given decument at diven #947689 From FRómset. to: tóséto 


RETRIEVEV  ZsPrecset? 


returns material (text and links) determined by srecset. 


RETRIEVEDNCVSPAN <Cdecid> 


retruns a span determining the orisin and extent of the vatream | 
ef the given document | 


RETRIEVEDOCVSPANSET <dorid> 


—_— чете: ONU 


returns a spanset determining all sections of thé:vatkealfi of tfi 
(Siven document correspondins to distinct ispans 


NG <“vepecasetS 
= Cvspec># 


returns a list af ali documents cantainind iny oë. нег mater тат 
de termined bv the siven vsPecset 


FINDLINKSFROMTO <homeset> <fromset> <toset> 
“homeset> := “specset> i 


returns а list of all links which are (1) ih homésst; (Zr ga ATIS 
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